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Abstract 


This document describes a joint recommendation of the Internet 
Architecture Board and the Internet Engineering Steering Group for 
administrative restructuring of the Internet Engineering Task Force. 
The IETF Chair declared that the IETF had consensus to follow this 
recommendation on November 11, 2004. Further work has been done to 
revise and refine the structures proposed. The recommendation is 
being published for the record. 
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Les 


Introduction 


The Internet Engineering Task Force (IETF) has a need for 
administrative support functions. The debate and dialogue of 2003 
and 2004 has led to the belief that the way these functions are 
provided needs to be changed. 


This document gives the recommendation of the Internet Engineering 
Steering Group (IESG) and Internet Architecture Board (IAB) on what 
the next step in that change process should be, and some of the 
background and reasoning behind this recommendation. 


The Process That Produced This Recommendation 


During several months in 2004, the Internet Architecture Board (IAB) 
and the Internet Engineering Steering Group (IESG) worked together to 
consider several different options for restructuring the Internet 
Engineering Task Force (IETF) administrative functions. The goal of 
this effort was to produce a recommendation for consideration by and 
approval of the IETF community. The rationale for this effort is 
described in RFC 3716 [1]. Much background work and several detailed 
proposals for community consideration are provided in a report 
prepared by a consultant titled "IETF Administrative Support 
Functions" [2]. 


The consultant’s report included several possible scenarios for 
administrative restructuring (named scenario A, B, C, and D). As 
discussion took place within the IETF community, it became clear that 
some of the scenarios had features that appeared more promising than 
others, but that we did not have enough of a concrete proposal to 
crystallize opinions into a consensus for action. Members of the 
IESG and IAB took on the task of working out more complete 
descriptions of two of the scenarios. They were: 


o Scenario C (section 4.4 of the report) describes when 
"administrative support functions for the IETF are legally housed 
in a focused, incorporated institution" with close ties to the 
Internet Society (ISOC). Scenario C is included here as the first 
appendix. 


o A new scenario, called Scenario O, that includes features derived 
from scenarios A and B (sections 4.2 and 4.3 of the report), 
focusing on the formalization of the ISOC/IETF relationship while 
housing administrative support functions for the IETF within ISOC. 
Scenario O is included here as the second appendix. 
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These descriptions were not intended to close off discussion of other 
scenarios, but to focus discussion on what appeared to be two 
independent loci of support. 


Both scenarios were presented to the IETF community as mail notes 
(Scenario C [3], Scenario O [4]) sent to the IETF discussion list. 
IETF participants’ opinions, while quite divided on the subject, 
seemed to indicate a preference for Scenario O as a "lower risk 
operation", but some participants indicated that they felt unable to 
give an informed opinion, disagreed with the process, or declared the 
subject out of their field of competence. This discussion garnered 
perhaps 40 participants who contributed on the list. 


The IETF Chair then requested an informal poll of IETF opinion. 
People interested in participating in the poll were directed to a web 
site where their opinions could be noted, including whether they 


wanted to state an opinion or not. The raw poll results [5] were 
also shared with the community via a mail note to the IETF discussion 
List. 


The poll sparked additional discussion on the list, and not all 
participants agreed with the methodology of the poll. Taken with the 
discussion, though, the IESG and IAB members believe that there is a 
stronger indication of community support for change based on Scenario 
O than on other scenarios. The IESG and IAB members believe that 
Scenario O can be a workable basis for further progress, even if it 
is not the first preference for all members. Taken together, this 
has led to the IESG/IAB recommendation given below. 


3. Recommendation 


The collective recommendation of the IAB and IESG was presented to 
the IETF community of Friday 8 October 2004 via a mail note [6] sent 
to the IETF mailing list: 


"IETF folks, 

The IESG and IAB have been considering the input from the IETF 
community on the next steps going forward in IETF administrative 
restructuring. 

It appears clear to us that the community mostly sees scenario O 
as the lower-risk scenario, and the one that gives us the greatest 


probability of successfully doing what we have to do. 


Based on this, the IESG and the IAB make the following 
recommendation: 
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We recommend that the IETF pursue scenario O, with the 
understanding that further work is needed to define the 
roles and responsibilities of the IETF, the IAOC and the 
ISOC BoT under this scenario. 


The "BCP section" of the scenario O note will be pulled out and 
published as an internet-draft. We’d like to put this description 
to the IETF community for a formal Last Call before the November 
IETF meeting, if possible. 


Also, as noted in the recommendation above, there are a number of 
points where we need to work out in more detail how the system is 
going to work - who takes decisions, who accepts those decisions, 
and what conflict resolution mechanisms may be necessary, and so 
on. The IAB and IESG are drafting a document that will describe 
the finer level of detail as to the respective roles and 
responsibilities of each of the players. We will publish this as 
an internet-draft shortly. 


We will continue to work intensely on this!" 
4. Arguments That Had Particular Weight in the Discussions 
4.1. Focusing on Scenarios C and O 


The IETF list was presented with four scenarios in the consultant 
report [2], which should be read for the full context. In slogan 
form, they might be rendered as 


o A: Leave it to ISOC. 

o B: Increase IETF control of ISOC, and use ISOC to do it. 

o C: Isolate the functions, let ISOC gather money, share control. 
o D: Cut the IETF off from ISOC and do it ourselves. 


On the list, there seemed to be very few who were comfortable with 
the idea that "we" (for some version of "we") could "do it ourselves" 
as envisioned in Scenario D. There was also considerable worry about 
the risk associated with Scenario C, especially with regard to 
financial stability, and that the perceived danger of problems would 
cause sponsors to withhold funding, thus precipitating problems even 
if there was no other reason for them. Scenario C spoke strongly to 
those who worried about a possible conflict of interest between ISOC 
and the IETF community at some future date - "we don’t know what ISOC 
will turn into" was the capsule summary. 
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Scenario A worried people because it did not seem to acknowledge the 
IETF community’s ability to determine if its needs were being met and 
what could be done if they were not. The phrase "replace existing 
problematic structures by ISOC" was perhaps a capsule summary. 
However, Scenario B’s list of possible mechanisms for involving IETF 
community directly in ISOC’s operations was not viewed as acceptable 
or in balance with the full scope of ISOC’s activities. Members of 
the IAB & IESG developed Scenario O, a solution scenario that put the 
administrative activity within ISOC, but aimed to provide a means for 
the IETF to provide oversight and control of that specific activity 
within ISOC. Its name is derived from the classification of blood 
types -- "neither A nor B". 


Thus, the decision to focus on C and O as “alternatives to be worked 
out in detail" was made. 


4.2. Why We Chose Scenario O 


Capsule summary: It might be possible to make either scenario work. 
But Scenario O could be made to work faster, and less painfully. 


The ISOC Board of Trustees was significantly worried that scenario C 
would make fundraising more difficult, which would necessarily affect 
its ability to support the IETF. 


The question of tax status for the new corporation was debated at 
some length on the list; legal counsel indicated that a corporation 
that did the IETF work (Scenario D) would probably be easy to get 
classified as 501(c) (3) (a type of non-profit corporation defined by 
U.S. Internal Revenue Service (IRS) regulations). However, a 
corporation that did only administrative support functions, as 
scenario C envisioned, would have more problems. In all cases, the 
process of determining this would take months, and could be dragged 
out longer if we were unlucky. 


The community feedback, in addition to contributing many well-formed 
and well-argued points to the discussion, gave a powerful indication 
on where it was possible to get IETF consensus: 


o It seemed possible to garner IETF consensus around Scenario O; the 
people arguing for Scenario C indicated that they "could live 
with" the alternative. 


o It seemed much more difficult to garner IETF consensus around 


Scenario C; many people arguing against it indicated that they 
were firmly convinced that it was the wrong choice for the IETF. 


Hollenbeck Informational [Page 5] 


RFC 4089 TAB-IESG AdminRest Rec May 2005 


The IETF is based on the idea that the consensus process, when it 
works, comes up with reasonable decisions. We concluded that the 
apparent drift of community consensus was a reasonable basis for the 
IESG/IAB recommendations. 


5. IANA Considerations 


This document does not require any IANA actions. However, the IETF 
administrative restructuring process is likely to affect how the 
relationship between the IETF and the IANA is managed. 


6. Security Considerations 


This document does not introduce any security considerations for the 
operation of the Internet. However, administrative restructuring 
introduces several areas of risk to the future of the IETF. The 
risks and their mitigation strategies are described in the scenarios 
as appended to this document. 
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endix: Scenario C 


This Appendix reproduces the contents of an Internet-Draft defining 
Scenario C, as it was posted on 20 September 2004. A table of 
contents has been removed from this copy and the text has been 
reformatted to fit within IETF publication guidelines. Each line is 
prefixed with "C>>". 


B. Wijnen 
LucentTechnologies 

H. Alvestrand 

Cisco Systems 

P. Resnick 

QUALCOMM Incorporated 
September 20, 2004 


AdminRest Scenario C: An IETF Administrative Support Foundation as 
an Independent Nonprofit Corporation 


Abstract 


This document defines a proposal for an IETF Administrative 
Support Foundation (IASF) as an independent not-for-profit 
corporation as a means for providing focused support for IETF 
community activities. It proposes the creation of an IASF Board 
of Trustees (BoT) that is mainly selected by and accountable to 
the IETF community and would provide oversight for the IETF 
Administrative Support Foundation. The IASF will also establish 
and maintain a strong relationship with the Internet Society 
(ISOC) and the current relationships between IETF and ISOC will 
basically be left unchanged. 


In order to allow the community to properly evaluate this 
scenario, some draft Articles of Incorporation and draft Bylaws 
for the IASF are included. Some draft BCP wording for the IASF, 
IETF and ISOC relationships is also included. 


1. Overview of Scenario C 


This document follows from two previous documents. [RFC3716] 
defined the overall parameters and criteria for an administrative 
restructuring. [I-D.malamud-consultant-report] provided an 
analysis of the implications of several of the suggested 
strategies. This document picks one strategy and develops it 
further. 
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In order to provide the most focused and effective administrative 
support to the IETF community, this updated scenario C proposes a 
new and well-defined legal entity to support the IETF 
administrative functions. The name of that new entity is "The 
IETF Administrative Support Foundation" (IASF). 


First, it is important to understand that the IETF has been 
organized as an Activity of the Internet Society (ISOC) and as 
such represents the "Standards and Protocols" pillar of ISOC. 
Under this proposal, the IETF would continue to be an integral 
part of the Standards and Protocols pillar of ISOC. ISOC 
currently provides these important functions to the IETF: 


1. Standards Process Functions. ISOC plays a fundamental role in 
the IETF Standards Process, including appointment of the 
Nominating Committee (Nomcom) chair, confirmation of IAB 
members, confirmation of documents that describe the 
standards processes, and acting as the last resort in the 
appeals process. These Standards Process Functions are 
defined in [RFC2026], [RFC2028], [RFC2031], and [RFC3677]. 


2. IETF Fund Raising Functions. ISOC provides the fund raising 
function as one source for financial support the IETF. 


3. Administration Functions. ISOC provides administrative and 
financial functions, managing the contract with the RFC 
Editor, providing insurance for selected IETF participants, 
and administering a discretionary fund for use by the IAB and 
the IETF Chairs. 


The administrative restructuring of the IETF proposed in this 
document keeps that basic relationship between IETF and ISOC. 
Specifically, the recommendation does not propose any changes to 
the "Standards Process Functions" or to the "IETF Fund Raising 
Functions". 


Under the "Administration Functions", ISOC both funds and 
administers some (as stated above) parts of the IETF 
Administrative Support Functions. Some of the funds (like for 
the RFC-Editor) go directly to the contractor who executes the 
administrative function. The streamlining of the administrative 
support for the IETF ultimately intends to put the complete 
Administrative Support Functions under the newly recommended 
IASF. This means that we recommend that ultimately, ISOC funds 
for the IETF will be transferred to the IASF, which will then 
administer all the contracts and payments according to an 
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approved yearly budget. The details of that process will be 
documented in a Memorandum of Understanding (MoU) between ISOC, 
IETF and IASF. 


This updated AdminRest Scenario C aims to provide the following: 
o A continued close relationship between IETF and ISOC. 


o A well defined legal entity within which the IETF can define 
the administrative activity in terms of IETF community needs. 


o A Board of Trustees with operational oversight that is 
accountable to the IETF community. 


o Continued separation between the IETF standards activity and 
any fund-raising for standards work. 


o A close and well defined relationship between IASF and ISOC, 
documented in a BCP (or MoU). 


o Appropriate ISOC oversight of its standards activities funds 
via a yearly budget approval and open reporting of funds 
spent. 


In scenario C, it is intended that the IETF Administrative 
Support Foundation will be a tax-exempt not-for-profit 
corporation as defined by Articles of Incorporation and a set of 
Bylaws. These will describe the scope and purpose of the IASF 
and they also define the structure and responsibility of the 
Board of Trustees (BoT), a body that is mainly selected by the 
IETF and which is responsible for overseeing the IASF. A draft 
of the Articles of Incorporation and Bylaws is included in the 
next sections of this document. 


Scenario C allows us (IETF) to establish IETF control over our 
administrative support functions in terms of determining that 
they meet the community’s needs, and adjusting them from time to 
time using IETF processes. This is to address the pressing 
administrative issues outlined in [RFC3716]. 


Scenario C also encourages us (the IETF) to regularly evaluate 
that we do want to continue the relationships with ISOC and the 
contracts with our services providers (contractors). It is based 
on the premise that we prefer to actively maintain relationships 
with other organizations and service providers instead of being 
bound to such relationships based on poorly defined and poorly 
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documented historical facts. A draft BCP for the relationship 
between ISOC, IETF and IASF is included as a separate section in 
this document. 


Scenario C does however bring the burden of creating a new legal 
entity (IASF) and such an undertaking is also not without risks. 
It will need careful planning and execution. Migration from the 
current structure to this new structure is probably also somewhat 
more costly and time and labour consuming. The sections below 
try to show how that would be achieved and outlines what further 
steps are needed to provide more detail if this scenario is 
chosen. 


Work Plan for the IETF Administrative Support Foundation 


This section gives the work plan for the IETF Administrative 
Support Foundation (IASF) for the remainder of 2004 and the year 
2005. 


.1 Workplan goals 


The work plan below is intended to satisfy three goals: 

o Satisfy the IETF’s need for support functions in 2005 

o Operate with a positive account balance throughout 2005 

o Start building up a fund inside the IASF to serve as a buffer 
against budgetary emergencies in later years (such as meetings 
with a severe cost overrun, or force-majeure cancellations). 

The fund target is 6 months of operating revenue, and the target 


for building up the fund is 3 years. The budgeted set-aside for 
the fund should thus be approximately 17% of operating revenue. 


-2 Incorporation process 


There are 3 things that need to be in place before that 
corporation can be considered viable at all: 


o IETF consensus on the plan 
o ISOC agreement on a reasonable support contract 


o Assurance that the corporation will have tax-exempt status 
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Once this document has been discussed in the IETF, and the IESG 
and IAB gauges that rough consensus seems reached, the IETF 
leadership will take the following actions: 


o Publish a Last Call on this document (to determine plan 
consensus). 


o Choose a negotiating team to negotiate the ISOC contract. 


o Choose an executive search team to find the IASF 
Administrative Director (IAD). 


o Consult with legal counsel to determine how best to achieve 
tax-exempt status; this will affect the bylaws and articles of 
incorporation. 


When the Last Call is over, the IESG will consider whether there 
is still consensus, and if there is, approve this document for 
publication. Once that happens, it will take the following 
steps: 


o As soon as negotiations conclude, publish a Last Call on the 
ISOC contract. 


o As soon as drafting of legal documents is completed, publish a 
Last Call on the Bylaws and Articles of Incorporation, and ask 
the Nomcom to start the process of selecting Nomcom-selected 
board representatives. 


These Last Calls are "speak now" Last Calls - if someone wishes 
to challenge the IETF consensus to go ahead with these actions, 
knowing what the formal documents will look like, this is their 
last chance. 


When these Last Calls are over, the IETF chair, the IAB chair and 
the ISOC President will jointly file the articles of 
incorporation, and the IESG, IAB and ISOC will fill their board 
seats. 


Note: This document does not say when a Request for Information 
(RFI) for IETF support services such as meeting planning is sent 
out. Advice is sought on the earliest point where this can be 
done. 
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Contract establishment 


The most important activity for late 2004/early 2005 is to 
finalize contracts for the support of the IETF. This includes: 


o Funding 

o Technical infrastructure 
o Meeting management 

o Clerk’s office 

o RFC Editor 

o IANA 


There appears to be consensus in the IETF community that these 
functions, whether they are offered for free, remunerated or 
arranged for other consideration, should be under contract. 


The contract for funding is expected to be with ISOC, and should 
be finalized before IASF is established. 


The contract for technical infrastructure is expected to be an 
RFP, published in November of 2004, with responses being 
evaluated in December 2004, and services rendered from a mutually 
agreed date early in 2005. 


The contract for meeting management will be influenced by the 
need to have stable agreements for the 2005 meetings at an early 
date. This indicates that IASF will honor a pre-IASF agreement 
to have these meeting contracts signed by Foretec (if that can be 
achieved). 


It is not clear how the contract for the clerk’s office is to be 
managed at the time of this writing. 


The contract for the RFC Editor is expected to be with ISI, and 
is expected to be a continuation of the current contract with 
ISOC, which runs until the end of 2005. 


The contract with IANA will replace or augment the current MoU 
between the IETF and ICANN. In its simplest form, it would 
simply be a reconfirmation of the duties of ICANN under the MoU. 
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.4 Performance evaluation 


The second task of the IASF is to make sure the IETF gets the 
support it needs. The IASF will work together with the IETF 
community to make an effort to identify whether or not the IETF’s 
needs are being met, and to coordinate improvements with the 
contractors. This is an ongoing activity. 


-5 Budgeting for 2006 


In June 2005, the IASF will start the yearly budgeting process 
with ISOC, as specified in the ISOC contract, leading to a work 
plan and budget for 2006. 


-6 Reporting 


The IASF will present monthly updates on its economic status. 
These will be delivered to ISOC as part of the ISOC contract, and 
also be made publicly available so that the IETF community can 
inspect them. 


Details of the IETF Administrative Support Foundation 


This section contains details about the proposal to change how 
the day-to-day IETF administrative support functions are 
provided. This recommendation is based on the initial 
description of "Scenario C" in the "Administrative Support 
Analysis" [I-D.malamud-consultant-report] provided by Carl 
Malamud. It is further based on discussion in the IESG and IAB 
and on feedback on Carl’s document as received on the IETF 
mailing list. Further justifications, reasoning and motivations 
are given in Appendix A. Risk Analysis is done in Appendix C. 


This document recommends to create a well defined and legal 
entity called "The IETF Administrative Support Foundation" 


(IASF). The name intends to clearly express that this new legal 
entity has only one single function, namely to provide the 
administrative support of the IETF Standardization and Protocol 
Development activities. This entity will ultimately manage and 
administer all the administrative functions that are needed to 
support the IETF - the Standardization and Protocol Development 
activity of ISOC. 
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The consultant report [I-D.malamud-consultant-report] contains a 
writeup on various choices in terms of how and where to 
incorporate. This recommendation has made the choice to 
incorporate in the US in the state of Virginia. Some detail can 
be found in Appendix B. 


In this scenario, administrative support functions for the IETF 
are legally housed in a focused, incorporated institution 
(although the Administrative Director might be physically housed 
within the Internet Society). 


This scenario defines a number of concrete linkages with the 
Internet Society, which supplement the current close 
interconnection of the IETF community with ISOC. The 
relationship is to be documented in a MoU (initial text is in 
Section 4). 


-2 Draft Core Principles 


-2.1 Principles of Establishment and Governance 


The following principles are to be respected for the 
establishment and governance of the IETF Administrative Support 
Foundation (IASF) and are the basis for the Draft Articles of 
Incorporation as in Section 6.1 and the Draft Bylaws as in 
Section 6.2: 


1. The IASF shall be governed by a Board of Trustees (BoT), who 
shall be responsible for the fiscal, legal, and 
administrative infrastructure that supports the activities of 
the IETF. 


2. The governance of the IETF, the standards process, and all 
other aspects of how we make our standards are defined in the 
procedural Best Current Practice (BCP) RFC series, which will 
be explicitly referenced in the organization documents of the 
IASF. 


3. The IASF shall be transparent and responsible to the IETF. 
4. The BoT shall appoint a Secretary and a Treasurer, who need 


not be members of the BoT. The IETF Administrative Director 
(IAD) of the IASF shall provide staff support to the BoT. 
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5. The BoT shall be composed to strike a balance between 
"outside" and "inside" directors. The IESG and IAB will each 
select a representative to serve as a voting member of the 
BoT. Mechanisms such as the Nominating Committee (Nomcom) and 
the appointment of certain seats by the ISOC fulfill the 
outside director obligations. 


6. IAB, IESG and ISOC will have liaisons to the BoT in order to 
have a good basis for interaction. 


The BoT will have strong governance over a limited scope of 
activities (e.g., the fiscal, legal, and administrative 
infrastructure that are the charter of the IASF) but will have no 
authority over the IETF standards process. In this board 
composition, the ISOC and Nomcom appointments ensure that outside 
directors with no perceived conflicts of interest are on the 
board. 


All nominating bodies should make strong fiscal, legal, and 
administrative acumen essential selection criteria for this 
position. 


IAB and IESG representatives will serve for one year. For other 
appointments, a term proposed for the nominated positions is 
three years with staggered appointments. However, the nominating 
body might have the power to change their appointee during their 
term. 


All members of the BoT selected by the IETF are subject to the 
same recall procedures in effect for the IETF leadership such as 
members of the IAB and IESG. 


-2.2 Principles of Operation of the IETF Administrative Support 


Foundation 


The following are general principles for the operation of the 
IASF: 


1. The IASF shall employ an IETF Administrative Director (IAD) 
of the IASF, who shall be hired by the BoT with the advice 
and consent of the IESG and IAB. 


2. All support services shall be contracted in an open and 
transparent manner. 
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3. The IAD shall submit a proposed annual budget to the BoT at 
least 90 days before the beginning of the fiscal year. Such 
budget shall be developed with the advice and consent of the 
IAB and IESG. 


4. The IAD shall serve on the BoT as a non-voting, ex-officio 
member. 

5. The BoT shall select a professional audit firm and shall 
commission an audit immediately upon the close of each fiscal 
year. 


6. The IASF will conduct financial reporting in a fully 
transparent fashion. Audits shall be conducted promptly and 
published. Tax returns shall be published. Detailed 
financial statements will be published on a regular basis, 
including timely reports on the financial results of IETF 
meetings. 


Draft MoU between ISOC, IETF and IETF Administrative Support 
Foundation 


-l Form and Scope of the Agreement 


This section presents some principles to be incorporated in a 
draft MoU/Contract between the Internet Society (ISOC) and the 
IETF Administrative Support Foundation (IASF), detailing the work 
each is expected to perform, the responsibilities each has, and 
the means by which these functions are accomplished. This 
MoU/Contract shall be published as an RFC. 


The MoU/Contract will specify the responsibilities of the 
Internet Society, including: 


o Reaffirmation of the Standards Process Function that ISOC 
performs for the IETF. 


o Continuation of the Fund Raising Function that ISOC conducts, 
in which a single, unified campaign is used to solicit 
corporate, individual, and other organizational donations for 
funding of the 3 Pillars. 


o Disbursement of funds to the IASF according to the agreed-upon 
budgets and processes as specified in this agreement. 


o Verification that IASF spends these funds to support the work 
of the IETF, within the scope described in the IASF bylaws. 
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Responsibilities of IASF: 


(0) 


4.2 


Determine, in cooperation with the IETF, the support functions 
that are needed for the IETF, and can be achieved within 
available funds. 


Enter into contracts for these support functions. 
Supervise these contracts and ensure that they are being 
performed in the best interest of the IETF, within a 


reasonable budget and with agreed-upon performance. 


Cooperation mechanism 


TASF and ISOC agree that they will perform a budgeting procedure 
each year, comprising the following steps: 


(0) 


IASF puts together a budget proposal to ISOC, and presents it 
in June. This will specify the functions that need to be 
performed, the cost of each, the expected revenue from IETF 
meeting participation, and how much is being requested for 
ISOC to contribute. 


By the end of August, ISOC will give a budget number to IASF 
that says how much ISOC is willing to contribute to support 
the functions described in the IASF budget. 


Before November 1, ISOC and IASF will agree on a budget, an 
ISOC contribution, and a disbursement schedule. 


If either party sees that there is reason to change the 
budget, they can start a negotiation to do so at any time. On 
mutual agreement to a change, payments are modified 
accordingly. 


ISOC may withhold funds if IASF fails to account for its 
expenditures, if it determines that IASF has departed 
significantly from its budgeted expenditures without agreement 
with ISOC to do so, or if ISOC determines that IASF is 
spending funds in violation of its bylaws. 
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This section lays out things that would constitute interference 
in each others’ business, or things that are Just Plain Wrong. 


In legal terms, these are called "covenants." 


ISOC will not place requirements on how IASF does business, 
except on reporting. It will, for instance, not attempt to 
influence IASF choice of contractors or choice of meeting 
sponsors. This restriction is meant to enforce the separation 
between fund raising and the actual operation of the standards 
process. 


IASF will not ask companies for money.  IASF may ask for sponsors 
for IETF events, per tradition, and may accept zero-cost provider 
contracts or in-kind donations, but ISOC is the organization 
charged with fundraising. 


Neither ISOC nor IASF will attempt to influence technical 
decisions of the IETF standards process. 


-4 Initial contribution 


The Internet Society has already allocated $700,000 in transition 
funds. As part of the formation process, this section sets out a 
way that a 2005 allocation of funds and an initial contribution 
for startup can be decided upon. NOTE: This section is a GUESS! 
Its purpose is to give some sense of where we're at. 


If this plan is pursued, one of the first activities is to put 
together a detailed 2005 budget, including an analysis of cash 
flow and balance sheets to make sure that the organization is 
properly funded and will be solvent throughout the year. This 
planning process should project out 3 years and show how the 
organization will be able to accumulate the appropriate cash 
reserve to make sure operations can continue in a stable manner. 


An initial estimate is for an on-going annual contribution of USD 
900.000 to IASF in 2005. In addition, ISOC will contribute an 
additional USD 600.000 as an initial fund to start up IASF, 
payable after the Board of Trustees is seated and this contract 
is signed and approved by the IETF. 


ISOC commits to this ongoing level of contribution (USD 75.000 
per month) for the lifetime of this contract, unless modified by 
mutual agreement. 
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D3 


54 


5 


I3 


This agreement may be terminated by either party for any reason 
on 12 months’ notice. 


The parties may reach mutual agreement on a shorter termination 
period. 


All conflicts under this agreement are to be adjudicated under 
the laws of the United States and the State of Virginia, however 
the parties may also agree to arbitration, mediation or any other 
conflict resolution mechanisms. 


Notes and Explanations 
This is where we put down why things are the way they are. 
1 Type of legal instrument 


This document is styled as a contract - an agreement between two 
parties, enforceable under law. An alternate formulation would 
be a Memorandum of Understanding - but we want it to be clear to 
everyone that the parties stand behind their responsibilities 
under this document. At the moment, the authors see no 
compelling arguments for not making it a contract. In either 
case, the document is published as an RFC. 


.2 Power Balance 


As written, it is designed to make it easy to do the right thing 
as long as the parties agree what that is, to make it clear that 
ISOC will continue to pay money as long as IASF does the Right 
Thing (and reports what it’s doing), and that ISOC can stop the 
show quickly if it’s clear that IASF is not doing the Right 
Thing. 


3 Budget figures 


The main purpose of the numbers is to make it clear that there 
WILL be numbers in this contract, and that it WILL represent a 
solid commitment by ISOC. The numbers are "subject to change 

without notice" while this contract is negotiated. 
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Draft Incorporating Documents for the IETF Administrative 
Support Foundation 


1 Draft Articles of Incorporation 


This section contains standard, pro-forma Articles of 
Incorporation. Note well that tax lawyers often make significant 
alterations to standard Articles as they consider a 501 (c) (3) 
application. They are included here merely as a sample for 
illustrative purposes only. 


‘Commonwealth of Virginia -- State Corporation Commission’ | 
‘Articles of Incorporation -- Virginia Nonstock Corporation’ | 
Form SCC819, 07/ 03 [1] ------ 


The undersigned, pursuant to Chapter 10 of Title 13.1 of the Code 
of Virginia, [Virginia] state(s) as follows: 


1. The name of the corporation is The IETF Administrative 
Support Foundation. 


2. The corporation shall have no members. 

3. The purpose of the corporation is to manage and administer 
all the administrative functions for the IETF - the 
Standardization and Protocol Development activity of the 


Internet Society. 


4. The Trustees of the corporation shall be elected or appointed 
as specified in Article IV (Section 6.2.5) of the Bylaws. 


5. Name and agent: 


A. The name of the corporation’s initial registered agent 
is: XXX 


B. The initial registered agent is a domestic or foreign 
stock or nonstock corporation, limited liability company, 
or registered limited liability partnership authorized to 
transact business in Virginia. 


6. The initial Trustees are: XXX 


7. The incorporators are: XXX 
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C>> As with the Draft Articles, the Draft Bylaws included here are a 
C>> pro-forma, standard version. Substantial alteration may be 

C>> required as legal counsel reviews the specific nature of an 

C>> incorporation. 

C>> 

C>> 6.2.1 Article I: Organization 

C>> 

C>> The name of the Corporation shall be The IETF Administrative 

C>> Support Foundation (which is hereinafter also referred to as the 
C>> "ITASF"). 

C>> 

C>> 6.2.2 Article II: Purpose 

C>> 

C>> *Section 1: Purpose.* The IASF shall be operated exclusively for 
C>> nonprofit educational, charitable, and scientific purposes, 

C>> including, without limitation, the purposes stated in the IASF’s 
C>> Articles of Incorporation. 

C>> 

C>> *Section 2: Restrictions.* No part of the net earnings of the 
C>> IASF shall inure to the benefit of, or be distributable to, 

C>> private persons, except that the IASF shall be authorized and 
C>> empowered to pay reasonable compensation for services rendered, 
C>> and to make payments and distributions in furtherance of the 

C>> purposes set forth in Article II, Section 1 hereof. Any other 
C>> provision of these Bylaws to the contrary notwithstanding, the 
C>> TASF shall not carry on any activities not permitted to be 

C>> carried on by a corporation exempt from Federal Income Tax under 
C>> Section 501(a) and Section 501(c) (3) of the Code. These Bylaws 
C>> shall not be altered or amended in derogation of the provisions 
C>> of this Section. 

C>> 

C>> 6.2.3 Article III: Members 

C>> 

C>> The IASF shall have no members and no stockholders. 

C>> 

C>> 6.2.4 Article IV: Offices 

C>> 

C>> The office of the IASF shall be as determined from time to time 
C>> by the Board of Trustees (BoT) within or outside of the State of 
C>> Virginia. 

C>> 

C>> 6.2.5 Article V: Board of Trustees 

C>> 

C>> *Section 1: Authority and Responsibilities. * The power, 

C>> authority, property, and affairs of the IASF shall at all times 
C>> be exclusively exercised, controlled, and conducted by or under 
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the authority of the Board of Trustees (BoT) subject to any 
limitations set forth in the Articles of Incorporation and in 
accordance with the Virginia Nonstock Corporation Act as it now 
exists or hereafter may be amended. 


*Section 2: Board of Trustees Composition.* The Board of Trustees 
shall consist of seven (7) Trustees. 


One (1) Trustee will be selected by the IAB. 
One (1) Trustee will be selected by the IESG. 

Two (2) Trustees will be selected by the Internet Society. 
Three (3) Trustees will be selected by the IETF community. 
The IAB chair and IETF chair will functions as liaisons from the 
IAB and IESG respectively to the Board of Trustees. The chair 
and president of the Internet Society will function as liaisons 


from the ISOC to the Board of Trustees. 


*Section 3: Terms.* The term of office of IESG and IAB Selected 
Trustees shall be one (1) year or until their successors have 


been selected and assume office. The term of office of otherwise 
Selected Trustees shall be three (3) years or until their 
successors have been selected and assume office. Selected 


Trustees may be selected to serve multiple terms. 


*Section 4: Selection of the Board of Trustee* 


1. *Selection of IESG and IAB Selected Trustees.* The IESG and 
TAB shall each select one representative Trustee, who is not 
at the same time an IESG or IAB member. 


2. *Selection of otherwise Selected Trustees.* Three (3) IETF 
Selected Trustees shall be selected by the IETF nominations 
process (as defined in [RFC3777] or its successor) and 
confirmed by the IESG. Two ISOC Selected Trustees shall be 
selected by the Internet Society using means of their own 
choosing. 


3. *Resignation.* A Selected Trustee may resign by delivering 
his resignation in writing to the IASF at its principal 
office or to the Secretary of the IASF. Such resignation 
shall be effective upon its receipt or upon such date (if 
any) as is stated in such resignation, unless otherwise 
determined by the Board. 
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4. *Removal.* A Selected Trustee selected by the IETF 
nominations process may be removed from office at any time 
using the procedures specified in [RFC3777] or its successor. 
A Selected Trustee selected by the Internet Society may be 
removed by the Internet Society using means of their own 
choosing. 


5. *Vacancies.* Any vacancy in the Board of Trustees shall be 
filled using the procedures set forth above on the 
composition of the Board of Trustees. The Trustees shall 
have and may exercise all of their powers notwithstanding the 
existence of one or more vacancies in their number. 


*Section 5: Quorum.* A majority (i.e. fifty (50) percent plus 
one (1)) of the Trustees shall constitute a quorum for the 
transaction of business. Unless otherwise stated in these 


Bylaws, decisions of the Board of Trustees shall be made by the 
concurrence of a majority of members of the Board of Trustees 
present and voting. If at any meeting there is no quorum 
present, the Board must not transact business. 


*Section 6: Compensation and Reimbursement.* No member of the 
Board of Trustees may receive compensation for his or her 
services as a Trustee. A Trustee shall, at their request, be 
reimbursed for actual, necessary and reasonable travel and 
subsistence expenses incurred by them in performance of their 
duties. 


*Section 7: Meetings.* The Board of Trustees shall meet at least 
twice annually. 


1. *Written notice, waiver, action.* Wherever the text below 
speaks of "written" it is also permitted to use e-mail. 


2. *Annual Meeting.* The Board of Trustees shall hold a public 
Annual Meeting at a time and place associated with the first 
IETF meeting each year. This Annual meeting shall be open to 
all IETF attendees except that the parts of the meeting 
dealing with personnel issues may be held in executive 
session. 


3. *Meeting Types, Methods, and Notice.* Meetings of the Board 
may be held from time to time at such intervals and at such 
places as may be fixed by the Board. Meetings of the Board 
may be held only in person or via teleconference. Notice of 
all regular meetings of the Board shall be delivered to each 
Trustee by e-mail or by postal mail and announced on the 
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IETF-Announce list at least ten (10) calendar days before the 
meeting. Special meetings of the Board may be called for any 
purpose at any time by the Chairman of the Board or by any 
three (3) Trustees. Notice of any special meeting shall state 
the purpose of the meeting. A Trustee may waive notice of a 
meeting of the Board of Trustees by submitting a signed, 
written waiver of notice, either before or after the meeting. 
A Trustee's attendance at or participation in a meeting 
waives any required notice of the meeting unless at the start 
of such meeting or promptly upon arrival the Trustee objects 
to holding the meeting or transacting business at the 
meeting, and does not thereafter vote for or assent to action 
taken at the meeting. 


4. *Actions Taken By the Board of Trustees Without Meeting.* Any 
action required or permitted to be taken at any meeting of 
the Board of Trustees may be taken without a meeting if all 


Trustees consent in writing to such action. Such action 
shall be evidenced by written consents approving the lack of 
a meeting, signed by each Trustee. 


*Section 8: Board Committees.* The Trustees may elect or appoint 
one or more committees (including but not limited to an Executive 
Committee) and may delegate to any such committee or committees 
any or all of their powers, provided that any committee to which 
the powers of the Trustees are delegated shall consist solely of 
Trustees. Committees shall conduct their affairs in the same 
manner as is provided in these By Laws for the Trustees. The 
members of any committee shall remain in office at the pleasure 
of the Board of Trustees. 


*Section 9: Trustee Member Conflict of Interest.* 


1. As set forth in Section 9(3) below, a Trustee of the IETF 
Administrative Support Foundation (IASF) who has a personal 
interest in a transaction, as defined below, may not 
participate in any discussion of that transaction by the 
Trustees of The IASF and may not vote to determine whether to 
authorize, approve, or ratify that transaction except as 
specifically described below. For purposes of these Bylaws, a 
"personal interest" is defined as any act that will provide, 
directly or indirectly, a financial benefit or a disparate 
benefit individually to the Trustee, or to a company he or 
she is employed by, has a significant financial interest in, 


or represents in any fashion. However, policies under 
consideration by the IASF are likely to have an impact on the 
business of every Trustee. It is expected that most policy 
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decisions will have a direct or indirect impact on the 
Trustee’s company, but such a non-individualized interest 
does not constitute a "personal interest" as used in these 
Bylaws. A "transaction" with The IASF for purposes of these 
Bylaws is a contract or consultancy in which the Trustee has 
a direct or indirect financial benefit, or a policy under 
consideration that will have a disparate and unusual impact 
on a business with which the Trustee is directly or 
indirectly associated. 


The mere existence of a personal interest by a Trustee of The 
IASF in a transaction with the IASF shall not invalidate the 
IASF’s ability to enter that transaction so long as the 
following conditions are met: (i) the material facts of the 
personal nature of the transaction with The IASF and the 
Trustee’s interest in the transaction with the IASF are fully 
disclosed to the Board of Trustees of the IASF, either by the 
Trustee having a direct or indirect personal interest in the 


transaction with the IASF, or are brought to the attention of 
the Board by a third party; or (ii) the BoT of the IASF, by a 
vote of the Trustees (without a conflict of interest) of the 
IASF vote to authorize, approve, or ratify a transaction with 
the IASF; or (iii) the transaction with the IASF in which the 
direct or indirect personal interest of a IASF Trustee was 
disclosed to the BoT of The IASF and was determined by the 
BoT of the IASF entitled to vote on the matter is determined 
by the BoT voting to be in the IASF’s interests, 
notwithstanding the personal interest of the non-voting 
Trustee. 


In determining whether a conflict of interest exists, the BoT 
of the IASF has the prerogative, upon review of all facts and 
circumstances, to make its own determination of whether a 
conflict of interest exists and how it is appropriate to 
proceed. A Trustee who perceives the possibility of a 
conflict of interest for him or herself, or for another Board 
member, may raise this issue at any point prior to a vote on 
any issue. Any Trustee who perceives a possible conflict of 
interest may present justification with respect to whether or 
not a conflict of interest exists, but the entire Board, with 
the exception of the Trustee having the potential conflict of 
interest, shall make the final determination to proceed in 
such a matter. If the BoT finds there is a conflict of 
interest, the Trustee with the conflict may be excluded by 
the Chair of the Board from that portion of any meeting where 
a substantive discussion or decision to engage or not in such 
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a transaction is made, except that he or she may provide any 
information that will assist the Trustees in such a matter 
before leaving such a meeting. 


*Section 10. Approval of Meeting Minutes.* Minutes of the BoT of 
the IASF must be approved by a procedure adopted by the board and 
published on the IASF web site. 


6.2.6 Article VI: Officers 


*Section 1: Number.* The officers of the IASF shall consist of a 
Chairman of the Board, a Treasurer and a Secretary, and such 
other inferior officers as the BoT may determine. 


*Section 2: Election Term of Office and Qualifications.* All 
officers shall be elected annually by the vote of a majority of 
the Board of Trustees present and voting (excluding abstentions) 
at the Annual Meeting. The Treasurer and Secretary need not be 
members of the Board. The Chair of the IETF nor the chair of the 
IAB shall be the Chairman of the Board of the IASF. 


*Section 3: Resignation.* An officer may resign by delivering his 
written resignation to the IASF at its principal office or to the 
Chair or Secretary. Such resignation shall be effective upon 
receipt or upon such date (if any) as is stated in such 
resignation, unless otherwise determined by the Board. 


*Section 4: Removal.* The BoT may remove any officer with or 
without cause by a vote of a majority of the entire number of 
Trustees then in office, at a meeting of the BoT called for that 
purpose. An officer may be removed for cause only if notice of 
such action shall have been given to all of the Trustees prior to 
the meeting at which such action is to be taken and if the 
officer so to be removed shall have been given reasonable notice 
and opportunity to be heard by the BoT. 


*Section 5: Vacancies.* In case any elected officer position of 
the IASF becomes vacant, the majority of the Trustees in office, 
although less than a quorum, may elect an officer to fill such 
vacancy at the next meeting of the BoT, and the officer so 
elected shall hold office and serve until the next Annual 
Meeting. 


*Section 6: Chairman of the Board.* The Chairman of the Board 
shall, when present, preside at all meetings of the BoT of the 
IASF. If the Chairman is not available to preside over a 
meeting, the majority of the Trustees present shall select 
another Trustee to preside at that meeting only. 
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*Section 7: Treasurer.* The Treasurer shall have the custody of 
all funds, property, and securities of the IASF, subject to such 
regulations as may be imposed by the Board of Trustees. He or 
she may be required to give bond for the faithful performance of 
his or her duties, in such sum and with such sureties as the BoT 
may require or as required by law, whichever is greater. When 
necessary or proper, he or she may endorse on behalf of the IASF 
for collection, checks, notes and other obligations, and shall 
deposit same to the credit of the IASF at such bank or banks or 
depository as the BoT may designate. He or she shall make or 
cause to be made such payments as may be necessary or proper to 
be made on behalf of the IASF. He or she shall enter or cause to 
be entered regularly on the books of the IASF to be kept by him 
or her for that purpose, full and accurate account of all monies 
and obligations received and paid or incurred by him or her for 
or on account of the IASF, and shall exhibit such books at all 
reasonable times to any Trustee on application at the offices of 
the IASF incident to the Office of Treasurer, subject to the 
control of the BoT. Certain duties of the Treasurer as may be 
specified by the BoT may be delegated by the Treasurer. 


*Section 8: Secretary.* The Secretary shall have charge of such 
books, records, documents, and papers as the BoT may determine, 
and shall have custody of the corporate seal. The Secretary 
shall keep, or cause to be kept the minutes of all meetings of 
the BoT. The Secretary may sign, with the Chairman, in the name 
and on behalf of the IASF, any contracts or agreements, and he or 
she may affix the corporate seal of the IASF. He or she, in 
general, performs all the duties incident to the Office of 
Secretary, subject to the supervision and control of the Board of 
Trustees, and shall do and perform such other duties as may be 
assigned to him or her by the BoT or the Chairman of the BoT. 
Certain duties of the Secretary as may be specified by the BoT 
may be delegated by the Secretary. 


*Section 9: Other Powers and Duties.* Each officer shall have in 
addition to the duties and powers specifically set forth in these 
By Laws, such duties and powers as are customarily incident to 
his office, and such duties and powers as the Trustees may from 
time to time designate. 
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*Section 1: By Laws.* These By Laws may be amended by an 
affirmative vote of a majority of the Trustees then in office 
(excluding abstentions) at a regular meeting of the board or a 
meeting of the board called for that purpose as long as the 
proposed changes are made available to all trustees and posted to 
the IETF Announce list at least 30 days before any such meeting. 


*Section 2: Articles of Incorporation.* The Articles of 
Incorporation of the IASF may be amended by an affirmative vote 
of two-thirds of the BoT then in office at a regular meeting of 
the board or a meeting of the board called for that purpose as 
long as the proposed changes are made available to all trustees 
and posted to the IETF Announce list at least 30 days before any 
such meeting. 


-2.8 Article VIII: Dissolution 


Upon the dissolution of the IASF, the IASF, after paying or 
making provisions for the payment of all of the liabilities of 
the IASF, dispose of all of the assets of the IASF exclusively 
for the exempt purposes of the IASF in such manner or to such 
organization or organizations operated exclusively for social 
welfare or charitable purposes. Any such assets not so disposed 
of shall be disposed of by a court of competent jurisdiction of 
the county in which the principal office of the organization is 
then located, exclusively for such purposes. In the event of a 


sale or dissolution of the corporation, the surplus funds of the 
corporation shall not inure to the benefit of, or be 
distributable to, its Trustees, officers, or other private 
persons. 


6.2.9 Article IX: Miscellaneous Provisions 


*Section 1: Fiscal Year.* The fiscal year of the IASF shall be 
from January 1 to December 31 of each year. 


*Section 2: Execution of Instruments.* All checks, deeds, leases, 
transfers, contracts, bonds, notes and other obligations 
authorized to be executed by an officer of the IASF in its behalf 
shall be signed by the Chairman of the Board or the Treasurer, or 
as the Trustees otherwise determine. A certificate by the 
Secretary as to any action taken by the BoT shall as to all 
persons who rely thereon in good faith be conclusive evidence of 
such action. 
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*Section 3: Severability.* Any determination that any provision 
of these By-Laws is for any reason inapplicable, illegal or 
ineffective shall not affect or invalidate any other provision of 
these By-Laws. 


*Section 4: Articles of Incorporation. * All references in these 
By Laws to the Articles of Incorporation shall be deemed to refer 
to the Articles of Incorporation of the IASF, as amended and in 
effect from time to time. 


*Section 5: Gender.* Whenever used herein, the singular number 
shall include the plural, the plural shall include the singular, 
and the use of any gender shall include all genders. 


*Section 6: Successor Provisions.* All references herein: (1) to 
the Internal Revenue Code shall be deemed to refer to the 
Internal Revenue Code of 1986, as now in force or hereafter 
amended; (2) to the Code of the State of Virginia, or any Chapter 
thereof, shall be deemed to refer to such Code or Chapter as now 
in force or hereafter amended; (3) the particular sections of the 
Internal Revenue Code or such Code shall be deemed to refer to 
similar or successor provisions hereafter adopted; and (4) to the 
Request for Comment Series shall be deemed to refer to the 
Request for Comment Series as they are now in force or hereafter 
amended. 
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Security Considerations 


This document describes a scenario for the structure of the 
IETF’s administrative support activities. It introduces no 
security considerations for the Internet. 


Safety considerations for the integrity of the standards process 
are outlined in Appendix C. 


References 


1 Normative References 


[RFC2026] 


[RFC2028] 


[RFC2031] 


[RFC3677] 


[RFC3716] 


[RFC3777] 


[Virginia] 


Bradner, S., "The Internet Standards Process -- 
Revision 3", BCP 9, RFC 2026, October 1996. 


Hovey, R. and S. Bradner, "The Organizations Involved 
in the IETF Standards Process", BCP 11, RFC 2028, 
October 1996. 


Huizer, E., “IETF-ISOC relationship", RFC 2031, 
October 1996. 


Daigle, L. and Internet Architecture Board, "IETF ISOC 
Board of Trustee Appointment Procedures", BCP 77, RFC 
3677, December 2003. 


Advisory, IAB., "The IETF in the Large: Administration 
and Execution", RFC 3716, March 2004. 


Galvin, J., “IAB and IESG Selection, Confirmation, and 
Recall Process: Operation of the Nominating and Recall 
Committees", BCP 10, RFC 3777, June 2004. 


State of Virginia, "Title 13.1: Corporations, Limited 
Liability Companies, Business Trusts", Undated, 


<http://legl.state.va.us/cgi- 
bin/legp504.exe?000+cod+TOC1301000> 


-2 Informative References 


[I-D.ietf-xmpp-core] Saint-Andre, P., "Extensible Messaging and 


Hollenbeck 


Presence Protocol (XMPP): Core", draft-ietf-xmpp-— 
core-24 (work in progress), May 2004. 


Informational [Page 30] 


RFC 4089 


IAB-IESG AdminRest Rec 


May 2005 


"TETF Administrative 


Support Functions", draft-malamud-consultant-report—O0O1l 


[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 


clerkdl.pl?scc819&Articles_of_Incorporation_-—_Nonstock_Corpo 


C>> [I-D.malamud-consultant-report] Malamud, C., 
C>> 

C>> (work in progress), September 2004. 
C>> 

C>> 

C>> June 1999. 

C>> 

C>> URIs 

C>> 

C>> [1] <http://www.state.va.us/cgi-bin/scc-— 
C>> 

C>> ration> 

C>> 

C>> Authors’ Addresses 

C>> 

C>> Bert Wijnen 

C>> Lucent Technologies 

C>> Schagen 33 

C>> 3461 GL Linschoten 

C>> Netherlands 

C>> Phone: +31-348-407-775 

c>> EMail: bwijnen at lucent.com 

C>> 

C>> Harald Tveit Alvestrand 

C>> Cisco Systems 

C>> Weidemanns vei 27 

C>> Trondheim 7043 

C>> Norway 

C>> EMail: harald at alvestrand.no 

C>> 

C>> Peter W. Resnick 

C>> QUALCOMM Incorporated 

C>> 5775 Morehouse Drive 

C>> San Diego, CA 92121-1714 

C>> US 

C>> EMail: presnick at qualcomm.com 

C>> 

Hollenbeck Informational 


[Page 31] 


RFC 4089 TAB-IESG AdminRest Rec May 2005 


C>> Appendix A. Justification, Reasoning and Motivations 
C>> 


C>> 

C>> Quite a bit of the proposals from the consultant report have been 
C>> incorporated in this recommendation. However, a number of 

C>> changes have been made. In this section we try to explain which 
C>> changes were made and why. 

C>> 


C>> A.1 Changes to the name of the administrative entity 
C>> 


C>> In order to make it very clear that the new and legal 

C>> administrative entity is separate from the ISOC IETF activity 

C>> that deals with standardization and protocol development, this 
C>> recommendation uses "The IETF Administrative Support Foundation" 
C>> as the name for the corporation to be created. 

C>> 

C>> A.2 Domicile 

C>> 

C>> Various questions have been raised if the choice of Domicile 

C>> should be further investigated. In order to make progress this 
C>> document recommends to make a definite choice now and go for a US 
C>> based not-for-profit corporation in the state of Virginia. 

C>> Further investigation would most probably delay the whole process 
C>> by at least half a year. 

C>> 

C>> A.3 Changes to the composition of the BoT 

C>> 

C>> The consultant report had a proposal for Position-based Trustees, 
C>> which would automatically make the IAB chair and the IETF chair 
C>> voting members of the Board of Trustees (BoT) of the IETF 

C>> Administrative Support Foundation. There was discussion on the 
C>> IETF mailing list that those people are not selected because of 
C>> their business acumen but rather for their technical leadership. 
C>> We do not want to change those criteria. Another concern was 

C>> that this might generate a conflict of interest as well. So this 
C>> recommendation has made the IAB and IETF chairs liaisons to the 
C>> BoT. 

C>> 

C>> Instead of making IAB and IESG chairs voting Trustees, this 

C>> recommendation specifies that IAB and IESG can each select an 

C>> outside (i.e. not a member of IAB or IESG) person as a voting 
C>> Trustee. 

C>> 

C>> The selection of three (3) IETF selected Trustees has not changed 
C>> in this recommendation. However, there is a concern that the 

C>> current composition of the Nomcom is not tailored to selecting 
C>> people for this position. So over time a different process may 
C>> need to be defined for selecting those Trustees. 
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In order to balance the ISOC and IETF people present at the BoT 
meetings, this recommendation also specifies that the chair and 


president of ISOC also function as liaisons to the BoT of the 
IETF Administrative Support Foundation. 


Appendix B. Domicile of the IETF Administrative Support Foundation 


A U.S. non-profit, non-member corporation is being recommended. 
This recommendation is based on simple considerations of 
expediency and pragmatism: a transition will be simplest and 
least risky (in the short term). The reasoning is as follows: 


o Administrative support for the IETF is currently enmeshed in a 
series of relationships with other institutions, most of which 
are also U.S.-chartered non-profit organizations. Any change 
in the institutional status of administrative support 
functions will require familiarity with U.S. nonprofit law. 
Incorporation in another country would require familiarity 
with those laws as well. Thus, the incorporation expenses 
would be higher and the process would take longer. 


o U.S. law has a strong concept of "nexus," which is a 
determination of when a foreign organization has enough 
relationship to U.S. law to fall under the jurisdiction of a 
U.S. court. Because of a long history of operating in the 
U.S., numerous meetings in the U.S., and the large number of 
U.S. residents who are participants and leaders, we feel it is 
likely that U.S. courts would find nexus in relation to our 
US-based activities, even if the IETF administrative support 
organization was incorporated in another country. In other 
words, incorporating in a country besides the U.S. does not 
necessarily free the support organization from any perceived 
vagaries of U.S. law. 


o Incorporating in a country other than the US may have tax 
implications if the Internet Society is providing funding 
support. 


o It is very likely that the IETF Administrative Support 
Foundation would be deemed to clearly fall under the 
"scientific" and "educational" grounds for classification as a 
tax-exempt charity under section 501(c) (3) of the IRS code, so 
a tax-exempt application should be quite straight-forward. 


o The incorporation laws of the U.S. states being considered do 
not require that any members of the Board of Trustees be of a 
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certain nationality or state residency (e.g., there are no 
"local director" requirements). The U.S. Dept. of Commerce 
foreign-controlled organization reporting requirements apply 
only to "business enterprises", and do not apply to non-profit 


entities such as an IETF administrative support organization. 


Since this document recommends incorporating in the U.S., 
Virginia is the logical pick as the state of domicile to allow 
the IETF administrative support organization to make use of ISOC 
headquarters to house its single employee (though the employee 
might be able to be housed at the Internet Society even if the 
incorporation were elsewhere, for example the ISOC Geneva 
office). 


Appendix C. Risk Analysis 


This scenario (as do all scenarios) has some risks. This section 
tries to enumerate the sort of risks that we recognize and 
summarizes why we think we can accept the risk or what kind of 
action we think we can take if the risk indeed materializes into 
a problem. 


-l US Domicile risks 


As explained in [I-D.malamud-consultant-report], incorporating in 
the US carries two specific risks: the perception of the IETF 
being a US-based organization and the potential for (or 
perception of) governmental interference. 


The IETF is an international organization. However, even now, 
the fact that the IETF standards processes are run in English and 
that many of its current support organizations are US-based 
leaves an impression that the IETF is too US-centric. 
Incorporating the new administrative entity in the US may add to 
that perception. 


Also, the IETF history is based in US federal government research 
and funding. Though IETF is long separated from those 
beginnings, even in the past few years there have been 
interactions between the US government and the IETF that have 
concerned people. Incorporating the administrative entity in the 
US may invite more US governmental interference in the standards 
activity of the IETF, or at the very least may leave the 
perception that the US government might get involved. 


Both of these are serious problems, but we think there is 
justification for and at least one mitigation to these risks. Of 
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course, the primary reason to consider US incorporation is 
expedience (See section 4.4.1.1 of [I-D.malamud-consultant- 
report]). We agree that the expedience makes US incorporation 
worth the risk. But incorporating in multiple domiciles would 
significantly mitigate the risk. Assuming we go down the path of 


US incorporation, we would like legal counsel to advise on the 
possibility of incorporating in other domiciles (specifically 
Switzerland and The Netherlands) at a later date after US 
incorporation has been completed. If this is (as we suspect) 
indeed possible, we think this would be the best way to go 
forward. 


-2 Non-profit status risk 


One of the risks pointed out to incorporation was the potential 
that we would not get non-profit status, and that we must 
therefore preserve some money in escrow for tax liability 
purposes. Estimates for the time it will take to get such status 
can be several months or even longer in some cases. 


It is important to point out that the tax liability is based on 
profits, not on gross revenues. If the IASF is only taking in 
enough money to cover expenses, there would be very little tax 
liability. However, if more revenue is brought in than is spent, 
for example to build up an endowment or operating reserve, that 
"profit" is potentially taxable if non-profit status is not 
granted. 


To mitigate this risk, the corporation could be created and non- 
profit status applied for first, and operation of the corporation 
would only begin after non-profit status was obtained. The IETF 
would use an interim plan for continued operations until that 
time. This way, no money would need to be in escrow during the 
process of applying for non-profit status. However, that seems 
an excessively cautious path to take given what appears to be the 
fairly clear non-profit nature of the IETF. 


Commencing operations while the non-profit application is being 
considered, but being careful about balancing revenue with 
expenses and keeping an appropriate escrow account seems like a 
prudent task. Further, any fund raising campaigns that result in 
shifts to the balance sheet of the IASF should be conducted 
cautiously until non-profit status is granted. 
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It is important that the execution goes well. Risks that we are 
aware of include: 


o we can’t hire a good IAD 

o we fail to project cash flow properly and go insolvent 

o we can’t cut a deal with Foretec and have no 2005 meetings 

o we get bad lawyers and they take too long and charge too much 
o isoc runs out of money and doesn’t tell us early enough 

In order to mitigate these problems we have a proposed work plan 
included in this document. It is important that we get review of 


this work plan by as many eyes as we can get, to make sure we 
have considered all the possible steps that need to be taken. 


-4 Insolvency risk 


Improper management controls and procedures or other imprudent 
fiscal or administrative practices could expose the IETF to a 
risk of insolvency. Careful selection of trustees, a process of 
budget approval, and a methodical system of fiscal controls are 
necessary to minimize this risk. 


-5 Legal risks 


Improper formulation of the legal framework underlying the IETF 
may expose the institution and individuals in leadership 
positions to potential legal risks. Any such risk under this 
plan appears to be equivalent to the risk faced by the community 
under the current legal framework. This risk is further 
mitigated by a thorough review by legal counsel, and by use of 
insurance coverage. 


The legal exposure is best minimized by a careful adherence to 
our procedures and processes, as defined by the Best Current 
Practice Series. A carefully stated process, such as the BCP 
documents that govern the selection of leadership positions and 
define the standards process are the best insurance against legal 
exposure, provided care is taken to stick to the process 
standards that have been set. Adherence to a public rule book and 
a fully open process are the most effective mechanisms the IETF 
community can use. 
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This Appendix reproduces the contents of an Internet-Draft defining 
Scenario O, as it was posted on 20 September 2004. A table of 
contents has been removed from this copy and the text has been 
reformatted to fit within IETF publication guidelines. Each line is 
prefixed with "O>>". 


L. Daigle 
VeriSign 

M. Wasserman 
ThingMagic 
September 20, 2004 


AdminRest Scenario O: An IETF-Directed Activity Housed Under the 
Internet Society (ISOC) Legal Umbrella 


Abstract 


This document defines an alternative proposal for the structure 
of the IETF’s administrative support activity (IASA) -- an IETF- 
defined and directed activity that operates within the ISOC legal 
umbrella. It proposes the creation of an IETF Administrative 
Oversight Committee (IAOC) that is selected by and accountable to 
the IETF community. This committee would provide oversight for 
the IETF administrative support activity, which would be housed 
within the ISOC legal umbrella. In order to allow the community 
to properly evaluate this scenario, some draft BCP wording is 
included. 


1. Overview of Scenario O 


IETF community discussions of the scenarios for administrative 
restructuring presented in Carl Malamud’s consultant report [I- 
D.malamud-consultant-report] have led to the identification of a 
potentially viable alternative that is not included in that 
report -- an IETF-defined and directed administrative support 
function housed under the ISOC legal umbrella (called "IASA" 
hereafter). This new scenario retains some properties of the 
original ISOC-based scenarios, Scenarios A and B. However, this 
new scenario aims to provide: 


o continued close relationship with ISOC 
o a clear basis from which the IETF can define (and, over time, 


refine) the administrative activity in terms of IETF community 
needs, using existing IETF/ISOC processes 
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Oo an operational oversight board that is accountable to the IETF 
community 


o continued separation between the IETF standards activity and 
any fund-raising for standards work (within ISOC) 


O appropriate ISOC oversight of its standards activities funds 


This scenario is nicknamed "Scenario O" -- it is derived from, 
but does not entirely encompass, Scenario A or Scenario B. 


In Scenario O, the IETF administrative support function would be 
defined in a BCP that would be created via the IETF standards 
process [RFC2026] and approved by the ISOC Board of Trustees. 
This BCP would describe the scope of an IETF Administrative 
Support Activity (IASA) and would define the structure and 
responsibilities of the IETF Administrative Oversight Committee 
(IAOC), an IETF-selected body responsible for overseeing the 
IASA. Like the Internet Architecture Board (IAB), the IASA would 
be housed within the ISOC legal umbrella. The BCP would also 
describe ISOC’s responsibilities within this scenario, including 
requirements for financial accounting and transparency. A draft 
of this BCP is included in the next section of this document. 


Scenario O allows us to establish IETF control over our 
administrative support functions in terms of determining that 
they meet the community’s needs, and adjusting them from time to 
time using IETF processes. At the same time, it does not require 
that the IETF community determine, create and undertake the risks 
associated with an appropriate corporate structure (with similar 
financial infrastructure and tax-exempt status to ISOC’s) in 
order to solve the pressing administrative issues outlined in 
[RFC3716]. This proposal also defines the boundaries of the IASA 
so that it could be encapsulated and moved elsewhere at some 
future date, should that ever be desirable. 


Draft of Administrative Support BCP 


This section proposes draft text for a BCP that would define the 
scope and structure of the IASA. Although this text would 
require further refinement within the IETF community, this 
section is intended to be clear and complete enough to allow the 
community to reach a well-informed opinion regarding this 
scenario. 
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The IETF undertakes its technical activities as an ongoing, open, 
consensus-based process. The Internet Society has long been a 
part of the IETF’s standards process, and this document does not 
affect the ISOC-IETF working relationship concerning standards 
development or communication of technical advice. The purpose of 
this memo is to define an administrative support activity that is 
responsive to the IETF technical community’s needs, as well as 
consistent with ISOC’s operational, financial and fiduciary 
requirements while supporting the IETF technical activity. 


The IETF Administrative Support Activity (IASA) provides 
administrative support for the technical work of the IETF. This 


includes, as appropriate, undertaking or contracting for the 
work described in (currently, [RFC3716] but the eventual BCP 
should include the detail as an appendix), covering IETF document 
and data management, IETF meetings, any operational agreements or 
contracts with the RFC Editor and IANA. This provides the 
administrative backdrop required to support the IETF standards 
process and to support the IETF organized technical activities, 
including the IESG, IAB and working groups. This includes the 
financial activities associated with such IETF support 
(collecting IETF meeting fees, payment of invoices, appropriate 
financial management, etc). The IASA is responsible for ensuring 
that the IETF’s administrative activities are done and done well; 
it is not the expectation that the IASA will undertake the work 
directly, but rather contract the work from others, and manage 
the contractual relationships in line with key operating 
principles such as efficiency, transparency and cost 
effectiveness. 


The IASA is distinct from other IETF-related technical functions, 
such as the RFC editor, the Internet Assigned Numbers Authority 
(IANA), and the IETF standards process itself. The IASA is not 
intended to have any influence on the technical decisions of the 
IETF or on the technical contents of IETF work. 


.1.1 Structure of the IASA 


The IASA will be structured to allow accountability to the IETF 
community. It will determine the ongoing success of the activity 
in meeting IETF community needs laid out in this BCP, as well as 
ISOC oversight of its financial and resource contributions. The 
supervisory body defined for this will be called the IETF 
Administrative Oversight Committee (IAOC). The IAOC will consist 
of volunteers, all chosen directly or indirectly by the IETF 
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community, as well as appropriate ex officio appointments from 
ISOC and IETF leadership. The IAOC will be accountable to the 
IETF community for the effectiveness, efficiency and transparency 
of the IASA. 


The IASA will initially consist of a single full-time employee of 
ISOC, the IETF Administrative Director (IAD). The IAD will 
require a variety of financial, legal and administrative support, 
and it is expected that this support will be provided by ISOC 
support staff following an expense and/or allocation model TBD. 


Although the IAD will be a full-time ISOC employee, he will work 
under the direction of the IAOC. The IAD will be selected by a 
committee of the IAOC, consisting minimally of the ISOC President 
and the IETF Chair. This same committee will be responsible for 
periodically reviewing the performance of the IAD and determining 
any changes to his employment and compensation. In certain cases 
(to be defined clearly -- chiefly cases where the ISOC employee 
is determined to have contravened basic ISOC policies), the ISOC 
President may make summary decisions, to be reviewed by the 
hiring committee after the fact. 


The IAD will be responsible for administering the IETF finances, 
managing a separate bank account for the IASA, and establishing 
and administering the IASA budget. To perform these activities, 
the IAD is expected to have signing authority comparable to other 
ISOC director-level employees. Generally, expenses or agreements 
outside that authority to be approved for financial soundness as 
determined by ISOC policy. The joint expectation is that ISOC’s 
policies will be consistent with allowing the IAD to carry out 
IASA work effectively and efficiently. Should the IAOC have 
concerns about that, the IAOC and ISOC commit to working out 
other policies that are mutually agreeable. 


The IAD will also fill the role of the IETF Executive Director, 
as described in various IETF process BCPs. All other 
administrative functions will be outsourced via well-defined 
contracts. The IAD will be responsible for negotiating and 
maintaining those contracts, as well as providing any 
coordination that is necessary to make sure the IETF 
administrative support functions are properly covered. 


.1.2 IAD Responsibilities 


The day to day responsibilities of the IAD will focus on managing 
contracts with the entities providing the work supporting the 
IETF technical activity. 
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The IAD will provide regular (monthly and quarterly) reports to 
the IAOC and ISOC. 


All contracts will be negotiated by the IAD (with input from any 
other appropriate bodies), and reviewed by the IAOC. The 
contracts will be executed by ISOC, on behalf of the IETF, after 
whatever review ISOC requires (e.g., legal, Board of Trustees). 


The IAD will prepare an annual budget, which will be reviewed and 
approved by the IAOC. The IAD will be responsible for presenting 
this budget to the ISOC Board of Trustees, as part of ISOC’s 
annual financial planning process. The partnering is such that 
the IAOC is responsible for ensuring the suitability of the 
budget for meeting the IETF community’s needs, but it does not 
bear fiduciary responsibility; the ISOC board needs to review and 


understand the budget and planned activity in have enough detail 
of the budget and proposed plans to properly carry out its 
fiduciary responsibility. 


-1.3 IAOC Responsibilities 


The role of the IAOC is to provide appropriate input to the IAD, 
and oversight of the IASA functioning. The IAOC is not expected 
to be regularly engaged in IASA work, but rather to provide 
appropriate approval and oversight. 


Therefore, the IAOC’s responsibilities are: 
o Select the IAD, as described above. 


o Review the IAD's financial reports, and provide approval of 
the IAD’s budget proposals in terms of fitness for IETF 
purposes. 


o Review IASA functioning with respect to meeting the IETF 
community’s working needs. 


The IAOC’s role is to review, not carry out the work of, the IAD 
and IASA. As such, it is expected the IAOC will have monthly 
teleconferences and periodic face to face meetings, probably 
coincident with IETF plenary meetings, consistent with ensuring 
an efficient and effective operation. 
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O>> 2.1.4 IASA Funding 


The IASA is supported financially in 3 ways: 


1. IETF meeting revenues. The IAD, in consultation with the 
TAOC, sets the meeting fees as part of the budgeting process. 
All meeting revenues go to the IASA. 


2. Designated ISOC donations. The IETF and IASA do no specific 
fund raising activities; this maintains separation between 
fundraising and standards activities. Any organization 
interested in supporting the IETF activity will continue to 
be directed to ISOC, and any funds ISOC receives specifically 
for IETF activities (as part of an ISOC program that allows 
for specific designation) will be put in the IASA bank 
account for IASA management. 


3. Other ISOC support. ISOC will deposit in the IASA account, 
each quarter, the funds committed to providing as part of the 
IASA budget (where the meeting revenues and specific 


donations do not cover the budget). These funds may come 
from member fees or from other revenue streams ISOC may 
create. 


Note that the goal is to achieve and maintain a viable IETF 
support function based on meeting fees and specified donations, 
and the IAOC and ISOC are expected to work together to attain 
that goal. (I.e., dropping the meeting fees to $0 and expecting 
ISOC to pick up the slack is not desirable; nor is raising the 
meeting fees to prohibitive levels to fund all non-meeting-— 
related activities!). 


Also, in normal operating circumstances, the IASA would look to 
have a 6 month operating reserve for its activities. Rather than 
having the IASA attempt to accrue that in its bank account, the 
IASA looks to ISOC to build and provide that operational reserve 
(through whatever mechanism instrument ISOC deems appropriate -- 
line of credit, financial reserves, etc). Such reserves do not 
appear instantaneously; the goal is to reach that level of 
reserve by 3 years after the creation of the IASA. It is not 
expected that any funds associated with such reserve will be held 
in the IASA bank account. 
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IAOC Membership, Selection and Accountability 


Note: This section is particularly subject to change as we work 
to find the best way to achieve the key principles. The key 
principles being adhered to are that while this should be 
reasonably separate from IETF Standards process management: 


o the IETF and IAB Chairs need to be involved to a level that 
permits them to be involved in and oversee the aspects 
pertinent to their roles in managing the technical work (e.g., 
the IAB looks after the RFC Editor relationship) 


o the IETF and IAB Chairs must not be critical path to getting 
decisions to and through the IASA. 


The current draft, below, therefore makes the IETF Chair ex 
officio voting member of the IAOC, and the IAB Chair a non-voting 
liaison. Future versions may change either or both, depending on 
what makes sense to the IETF community in its deliberations. 


The IAOC will consist of seven voting members who will be 
selected as follows: 


o 2 members chosen by the IETF Nominations Committee (NomCom) 

o 1 member chosen by the IESG 

o 1 member chosen by the IAB 

o 1 member chosen by the ISOC Board of Trustees 

o The IETF Chair (ex officio) 

o The ISOC President/CEO (ex officio) 

There will also be two non-voting, ex officio liaisons: 

o The IAB Chair 

o The IETF Administrative Director 

The voting members of the IAOC will choose their own chair each 

year using a consensus mechanism of its choosing. Any appointed 
voting member of the IAOC may serve as the IAOC Chair (i.e., not 
the IETF Chair or the ISOC President/CEO). The role of the IAOC 
Chair is to organize the IAOC. The IAOC Chair has no formal 


duties for representing the IAOC, except as directed by IAOC 
consensus. 
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The members of the IAOC will typically serve two year terms. 
Initially, the IESG and ISOC Board will make one-year 
appointments, the IAB will make a two-year appointment, and the 
Nomcom will make one one-year appointment and one two-year 
appointment to establish a pattern where approximately half of 
the IAOC is selected each term. 


The two NomCom selected members will be selected using the 


procedures described in RFC 3777. For the initial selection, the 
IESG will provide the list of desired qualifications for these 
positions. In later years, this list will be provided by the 
IAOC. 


While there are no hard rules regarding how the IAB and the IESG 
should select members of the IAOC, it is not expected that they 
will typically choose current IAB or IESG members, if only to 
avoid overloading existing leadership. However, they should 
choose people who are familiar with the administrative support 
needs of the IAB, the IESG and/or the IETF standards process. It 
is suggested that a fairly open process be followed for these 
selections, perhaps with an open call for nominations and/or a 
period of public comment on the candidates. The IAB and IESG are 
encouraged to look at the procedure for IAB selection of ISOC 
Trustees for an example of how this might work. 


Although the IAB and IESG will choose some members of the IAOC, 
those members will not directly represent the bodies that chose 
them. All members of the IAOC are accountable directly to the 
IETF community. To receive direct feedback from the community, 
the IAOC will hold an open meeting at least once per year at an 
IETF meeting. This may take the form of an open IAOC plenary or 
a working meeting held during an IETF meeting slot. The form and 
contents of this meeting are left to the discretion of the IAOC 
Chair. 


Decisions of IAOC members or the entire IAOC are subject to 
appeal using the procedures described in RFC 2026. The initial 
appeal of an individual decision will go to the full IAOC. 
Appeals of IAOC decisions will go to the IESG and continue up the 
chain as necessary (to the IAB and the ISOC Board). The IAOC 
will play no role (aside from possible administrative support) in 
appeals of WG Chair, IESG or IAB decisions. 
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In the event that an IAOC member abrogates his duties or acts 
against the bests interests of the IETF community, IAOC members 
are subject to recall using the recall procedure defined in RFC 
3777. IAB and IESG-appointed members of the IAOC are not subject 
to recall by their appointing bodies. 


.3 IASA Budget Process 


While the IASA sets a budget for the IETF’s administrative needs, 
its budget process clearly needs to be closely coordinated with 
Isoc’s. The specific timeline will be established each year, 
before the second IETF meeting. A general annual timeline for 
budgeting will be: 


July 1 The IAD presents a budget proposal (for the following 
fiscal year, with 3 year projections) to the IAOC. 


August 1 The IAOC approves the budget proposal for IETF purposes, 
after any appropriate revisions. As the ISOC President is 
part of the IAOC, the IAOC should have a preliminary 
indication of how the budget will fit with ISOC’s own 
budgetary expectations. The budget proposal is passed to the 
ISOC Board of Trustees for review in accordance with their 
fiduciary duty. 


September 1 The ISOC Board of Trustees approves the budget 
proposal provisionally. During the next 2 months, the budget 
may be revised to be integrated in ISOC’s overall budgeting 
process. 


November 1 Final budget to the ISOC Board for approval. 


The IAD will provide monthly accountings of expenses, and will 
update forecasts of expenditures quarterly. This may necessitate 
the adjustment of the IASA budget. The revised budget will need 
to be approved by the IAOC and ISOC Board of Trustees. 


-4 Relationship of the IAOC to Existing IETF Leadership 


The IAOC will be directly accountable to the IETF Community. 
However, the nature of the IAOC’s work will involve treating the 
IESG and IAB as internal customers. The IAOC should not consider 
its work successful unless the IESG and IAB are satisfied with 
the administrative support that they are receiving. 
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O>> 2.5 ISOC Responsibilities for IASA 


O>> 

O>> Within ISOC, support for the IASA should be structured to meet 
O>> the following goals: 

O>> 

O>> Transparency: The IETF community should have complete visibility 
O>> into the financial and legal structure of the ISOC standards 
O>> activity. In particular, the IETF community should have access 
O>> to a detailed budget for the entire standards activity, 

O>> quarterly financial reports and audited annual financials. In 
O>> addition, key contract material and MOUs should be publicly 
O>> available. Most of these goals are already met by ISOC today. 
O>> The IAOC will be responsible for providing the IETF community 
O>> with regular overviews of the state of affairs. 

O>> 

O>> Unification: As part of this arrangement, ISOC’s sponsorship of 
O>> the RFC Editor, IAB and IESG, as well as insurance coverage 
O>> for the IETF will be managed as part of the IASA under the 

O>> IAOC. 

O>> 

O>> Independence: The IASA should be financially and legally distinct 
O>> from other ISOC activities. IETF meeting fees should be 

O>> deposited in a separate IETF-specific bank account and used to 
O>> fund the IASA under the direction and oversight of the IAOC. 
O>> Any fees or payments collected from IETF meeting sponsors 

O>> should also be deposited into this account. This account will 
O>> be administered by the IAD and used to fund the IASA in 

O>> accordance with a budget and policies that are developed as 
O>> described above. 

O>> 

O>> Support: ISOC may, from time to time, choose to transfer other 
O>> funds into this account to fund IETF administrative projects 
O>> or to cover IETF meeting revenue shortfalls. There may also 
O>> 

O>> be cases where ISOC chooses to loan money to the IASA to help 
O>> with temporary cash flow issues. These cases should be 

O>> carefully documented and tracked on both sides. ISOC will 

O>> work to provide the 6 month operational reserve for IASA 

O>> functioning described above. 

O>> 

O>> Removability: While there is no current plan to transfer the 

O>> legal and financial home of the IASA to another corporation, 
O>> the IASA should be structured to enable a clean transition in 
O>> the event that the IETF community decides, through BCP 

O>> publication, that such a transition is required. In that 

O>> case, the IAOC will give ISOC a minimum six months notice 

O>> before the transition formally occurs. During that period, 
O>> the IAOC and ISOC will work together to create a smooth 
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transition that does not result in any significant service 
outages or missed IETF meetings. All contracts that are 
executed by ISOC as part of the IASA should either include a 
clause allowing termination or transfer by ISOC with six 
months notice, or should be transferrable to another 
corporation in the event that the IASA is transitioned away 
from ISOC in the future. Any accrued funds, and IETF-specific 
intellectual property rights (concerning administrative data 
and/ or tools) would also be expected to be transitioned to 
any new entity, as well. 


Within the constraints outlined above, all other details of how 
to structure this activity within ISOC (as a cost center, a 
department or a formal subsidiary) should be determined by ISOC 
in consultation with the IAOC. 


3. Workplan for Formalizing the IETF Administrative Support 

Activity 
This section proposes a workplan and schedule for formalizing the 
IETF administrative support activity (IASA) for the remainder of 
2004 and 2005. 

3.1 Workplan Goals 


This workplan is intended to satisfy four goals: 


(0) 


Satisfy the IETF’s need for support functions through 2005, 
with a careful transition that minimizes the risk of 
substantial disruption to the IETF standards process. 


Establish IETF community consensus and ISOC approval of a BCP 
formalizing the IASA as described in this scenario before any 
actions are taken that will have long term effects (hiring, 


contacts, etc.) 


Make sure that decisions with long term impact, such as hiring 
the IAD and establishing contracts for administrative support, 
are made by people chosen for that purpose who will be 
responsible to the community for the effectiveness of this 
effort (the IAD and members of the IAOC) -- not by our already 
overloaded technical leadership. 


Within the above constraints, move as quickly as possible 
towards a well-defined administrative support structure that 
is transparent and accountable to the IETF community. 
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There are three major elements to this workplan which can, to 
some degree, take place in parallel after we establish IETF 
community consensus to pursue Scenario O: 


o Finalizing the BCP text and getting it approved by the IETF 
community and ISOC. 


o Selecting IASA leadership. This includes appointing an 
interim IAOC, recruiting the IAD, and eventually appointing 
the full IAOC. 


o Negotiating agreements with service providers. This includes 
determining the structure and work flow of the IASA, deciding 
which portions of the IASA should be staffed via an open 
request for proposals (RFP) process, and issuing a RFP for 
those portions, as well as establishing sole source contracts 
or MOUs for other portions of the IASA. 


Each of the three items listed above is described in more detail 
in the following sections. 


-3 Approval by the IETF Community and ISOC 


In scenario O, the IASA is formalized in a BCP that is approved 
by the IETF community and accepted by the ISOC Board of Trustees. 
There are three steps in this process: 


1. Establishment of IETF community consensus that we should 
pursue Scenario O as defined in a joint IAB/IESG 
recommendation based on this proposal. This consensus will 
be established through community discussion and a formal two- 
week consensus call issued by the IETF chair on the IETF 
mailing list. 


2. Establishment of IETF community consensus on a BCP that 
formalizes the IASA as described. This consensus would be 
established through public discussion, a four week IETF Last 
Call and IESG review and approval. 


3. ISOC approval of the BCP and acceptance of ISOC’s 
responsibilities as described therein. This approval and 
acceptance would be signified by an ISOC Board resolution. 


The timeline for these three stages is rather long, but there is 
significant progress that can be made in other areas once we have 
established IETF community consensus to pursue this scenario. 
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-4 Selecting IASA Leadership 


Once we have IETF consensus to pursue this scenario, we can 
appoint an interim IAOC to begin working on the IASA transition. 
The interim IAOC could do substantial work on non-binding tasks, 
such as beginning the recruitment process for an IAD, determining 
the structure of the IASA work, issuing RFPs and negotiating 
potential agreements with service providers. The interim IAOC 
would not be empowered to make binding agreements, but could work 
appropriate consultants and advisors to make a lot of progress 
towards determining the initial structure and work flow of the 
IASA. 


Because the IETF Nominations Commitee (NomCom) process for new 
positions will consume a lot of resources and take a long time to 
complete, we propose that the interim IAOC consist of: 

o 1 IESG selected member 

o 1 IAB selected member 

o 1 ISOC selected member 

o The IETF Chair 

Oo The ISOC President/CEO 

The IAB chair will serve as a liaison, as described above. 

The IESG and ISOC Board appointments will be expected to serve 
until the first IETF meeting of 2006, and the IAB appointment 
will be expected to serve until the first IETF meeting of 2007, 


assuming that the BCP is approved and the IAOC continues to have 
appointed members from these bodies. 


After all of the interim IAOC members are selected, they will 
choose an interim IAOC chair from among the appointed members. 


When the BCP is approved, if the BCP indicates that there will be 
NomCom selected IAOC members they will be chosen at that time. 
Any adjustments to appointed members based on the BCP contents 
will also be made at that time. The IAOC will transition from 
interim to non-interim status when all non-interim members are 
seated. A new, non-interim chair selection process will then 
commence. 
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The interim IAOC should appoint an IAD selection committee to 
recruit and select the IETF Administrative Director. This 
committee will consist entirely of IAOC members or liaisons, and 
will, at minimum, include the IETF chair and the ISOC President. 
If the IAOC chooses, this committee could include the entire 
IAOC. 


The IAD selection committee should determine a job description 
for the IAD, in consultation with other IETF leaders and the IETF 
community. Once the job description is established, the IAD 
selection committee should recruiting candidates for the 
position. 


Although the interim IAOC is not empowered to hire the IAD as a 
full-time employee, it might be possible for the IAOC to ask ISOC 
to engage the potential IAD as a consultant to help with other 
tasks during the interim period. 


-6 Establishing Agreement with Service Providers 


The most important activity of the IAOC during late 2004 and 
early 2005 will be to determine the structure and work flow of 
the IASA and to establish contracts or other agreements with 
service providers to do the required work. This work includes 
the following functions as defined in the consultant’s report: 


o Technical infrastructure 

o Meeting management 

o Clerk’s office 

o RFC Editor services to support IETF standards publication 
o IANA services to support IETF standards publication 


The interim IAOC should work with IETF leaders and other 
knowledgeable members of the community to determine the structure 
and work flow required for the IASA activity and make 
corresponding adjustments to the above list, if necessary. The 
interim IAOC can also identify which areas of IASA work should 
continue to be provided by existing IETF service providers, and 
work with those providers to establish proposed contracts or 
agreements for later approval by the non-interim IAOC. The IAOC 
can also choose to start an RFP process for any services that 
they believe should be filled through an open RFP process. 
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3> 


3: 


7 Establishing a 2005 Operating Budget 


Because the ISOC 2005 budgeting process will be finalized before 
the non-interim IAOC is seated, the interim IAOC should work with 
the ISOC staff and President to establish a proposed 2005 
operating budget for the IASA. Since this will happen in advance 
of full knowledge regarding the costs of 2005 operations, it may 
be subject to significant adjustment later. 


8 Proposed Schedule for IASA Transition 


As described above, the three stages of the IETF community and 
ISOC approval process will take some time. If the community 
chooses scenario O and we reach quick consensus on the details, 
an optimistic schedule for this approval would be: 


1. IETF discussion of this proposal and other scenarios through 
11-Oct-2005. IAB/IESG discusses this proposal with ISOC 
Board. 

2. IAB/IESG joint recommendation issued on 8-Oct-04, including 


full BCP proposal. 


3. Community discussion of the joint IAB/IESG recommendation 
through 22-Oct-04. 


4. Two-week community consensus call issued on the IETF list on 
23-Oct-04 regarding rough community consensus to pursue this 
direction and appoint an interim IAOC -- extends through 
IETF 61. IAOC selecting bodies begin search, based on 
expected community consensus. 


5. Rough community consensus declared on 8-Nov-04 to pursue 
Scenario O and appoint the interim IAOC. 


6. Interim IAOC seated on 15-Nov-04. Interim IAOC begins 
interim work outlined above, including establishment of 


estimated 2005 budget and IAD recruitment. 


7. BCP text discussed by community, IETF leadership and ISOC 
Board until we have something that represents rough 
community consensus that is acceptable to all. We hope that 
this could be completed by 6-Dec-04. 


8. Four week IETF Last Call issued for BCP on 6—-Dec-04 -- 
extends through 3-Jan-04. 
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7. 


7. 


9. Simultaneous IESG and ISOC Board approvals by 17-Jan-04. 
10. IAD officially hired in Jan 2005. 


11. NomCom seats IAOC members at the first IETF of 2005, moving 
the IAOC from interim to non-interim status. 


12. Formal agreements with all service providers in-place by 
June 2005. 


Security Considerations 
This document describes a scenario for the structure of the 
IETF’s administrative support activities. It introduces no 
security considerations for the Internet. 

IANA Considerations 
This document has no IANA considerations in the traditional 
sense. As part of the extended IETF family, though, IANA may be 
interested in the contents. 
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